AI 时代的招聘与范式转换

有一点说法我觉得是没错的，那就是未来，尤其是现在的 AI 时代，招聘的整个方式和体系都一定会逐渐改变。因为所谓的古法编程，它带来的收益会越来越低，而过去那些 Team Leader 所具备的技能价值会越来越高。这项核心技能是什么呢？就是验证。

AI 在生成上非常强，而过去程序员主要做的工作恰恰就是生成。这就导致我们传统的招聘和面试体系，都倾向于去核查生成能力，比如做白板题、考各种各样的知识，或者问你某个语法上的问题。

但是，AI 时代最重要的工作过程，已经从生成转移到了验证。关键点在于：我今天生成了一万行代码，请问这一万行代码是不是稳健的、可生产级运行的？有没有潜藏的坑？我认为一个好的 AI-native 工程师，他的核心技能应当就是去做验证——无论是去设计一套体系，通过过程来保证生产结果的稳健性；还是凭借自己足够强的品味和结构性洞察，能一眼看出来 AI 的这套设计需要改、该往什么方向改。他其实在时刻做着验证的工作。

这种验证的工作，也使得我们当今对于知识和技能的学习，需要转向另一个方向。我认为对于那种过于特化的任务，应当减少精力的投入；而那些高度可迁移的知识，才是未来我们要去学的。也就是说，当今的时代在一定程度上，真的是广度大于深度。

这并不是说深度不重要，而是广度能带给我们一大核心优势——索引上的优势。什么叫索引上的优势？就是当我遇到某个问题时，我可以立即想起来：「哦，我之前在哪里看过这个东西。」虽然我对它的深度不了解，但我知道有这么个东西存在。举个例子，我知道在做 Agent 的时候要做 Eval（评估）。如果我完全没接触过这个领域，我会有做 Eval 的意识吗？广度恰恰提供了这样一种能力，那就是在特定情况下，能让我立即调取一个我本来不深入了解的概念。而这往往是解决问题的关键钥匙。

索引带来的优势就在于，我可以快速用这个话题去问 AI。AI 的典型特点是，你不问的时候它可能根本不会主动回答，但一旦你问了，它就能回答得很深。只要我知道有这么回事，我就可以去查、去了解，深度在这个过程中是可以快速补上的。当然，补到什么程度取决于工程现场需要用到什么程度。对工程师来讲，够用才是最关键的。

同时，广度也会为验证提供优势。验证的关键，恰恰在于「知道自己哪里错了」。过去的 Team Leader 一眼就能看出某个地方设计不对，为什么 Junior 工程师看不出来？因为他没有相关的广度知识，他不知道自己不知道什么。如果我现在补足了广度，我也能意识到自己还有哪些认知盲区；虽然还没有真正意义上的 Senior 那么深刻，但我可以去问 AI，以前不知道该问什么，现在知道了。这就是索引的能力。

因此，可迁移性越高的知识，在当代越值得学习。在计算机科学里，这指的就是底层基础，比如标准的系统设计、算法、数据结构等等。至于刷 LeetCode，在我看来投入产出比不是特别高。除非你要去那种大厂，面临硬性门槛，需要刷一大堆 Hard 级别的题，且进去之后收益很高，那可能是值得投入的。但如果你的目的仅仅是进中小型厂，或者拿一个中位数的薪水，那么比起盲目刷题，去积累结构性的、可迁移的知识才是更重要的。比如去补足计算机基础、软件工程设计、架构设计、分布式系统等等。

这些在过去其实是架构师和 Leader 才要学的东西，但在今天，哪怕是一个 Junior 也应该掌握。我们整个学校体系，尤其是工程导向的学校体系，也应该朝这个方向改变，尤其是重视学生的架构设计能力和知识广度。AI 是我们的辅助，但想要判断它的辅助到底正不正确，需要的恰恰就是这种广度知识。

另一方面，深度的知识同样重要，但这取决于项目的规模和层级。如果是一个非常重要的项目，深度的知识仍然是必要的；但对于大部分普通的消费级产品来讲，可能真的用不到那么深。比如做一个中小型企业的项目，真的需要去考虑百万并发那种级别的深度吗？用不到。需要的时候再去学就行了。而且深度是存在阶梯的，按照一般人的职业晋升体系，流量从一万到十万再到百万级，如果你一直在这条路上走，深度的积累自然而然会增加。

至于算法题，我的态度是，像 Easy 或 Medium 这种难度，尤其是高频题，稍微刷个几十、一百道也就差不多了。完全没必要去卷千道题，那个投入产出比太低了。

这里还有一个核心点，那就是很多时候企业需要的真的只是一个「信号」，需要低成本地识别出你是一个可用的人才。对企业来说，招错一个人的代价远大于错过一个好人。因为错的人会带来减损，而错过好人最多只是没有额外收益。因此企业会更倾向于避免错误，尤其是破坏性的错误。

在当今时代，这种可识别的信号会越来越重要。这也是为什么我写博客的原因，我希望能把自己的见解和认知写出来，以此来提高外界对我知识体系的识别度，包括我对 AI 的理解、对架构设计的理解等。这至少能让企业在一定程度上对齐信息，快速了解我这个人的技术底色。

除了博客，GitHub 上的一些项目代码，本身也是一种质量的象征。我不会去标榜「项目全是我手写的」，这年头谁还古法编程，标榜手写反而有点虚伪了，代码当然有很多是 AI 生成的。但我认为，正因为是 AI 生成的，去读一读代码就能立马看出质量高低——会用 AI 的，和不会用的，哪怕是同样一个cc，也能用处截然不同的效果。比如是否有足够的测试覆盖？整体架构设计是否清晰？有没有真正考虑到 AI 长期参与编程后会产生的漂移问题？换言之，就是我之前所说的，你到底有没有去做好「验证」这个东西。

典型的多 Agent 协同问题就是，我让 AI 去改 A 模块，或者加一个小功能，结果它把我后面整个项目全改坏了。光是从代码的隔离上就能看出使用水平，没有做到位，就说明大概率还没踩过坑，那就是使用 AI 的技术还停留在比较早期的程度。在我看来，能不能把 AI 用好的关键点，就在于能不能把 AI 的行动范围限制住。harness 就其字面意思来说就是「马具」，可想让马儿跑起来，只有马具是不够的，骑马的人也得有足够的驾驶技巧。只有把范围限制住了，我们后面才能对它的每一个模块进行可靠的验证。

所以，一切其实还是落回到「可验证」上面。大概这就是我今天的一些感触。